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1 

BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to the transmission and storage of digital information across a 
network. More particularly, the invention relates to an improved system and method for 
caching and/or delivering various types of digital content using a plurality of network 
protocols. 

Description of the Related Art 

The World Wide Web (hereinafter "the Web") is a network paradigm which links 
documents known as "Web pages" locally or remotely across multiple network nodes (i.e., 
Web servers). A single Web page may have links (a.k.a., "hyperlinks") which point to 
numerous other Web pages. When a user points and clicks on a link using a cursor control 
device such as a mouse, the user can jump from the initial page to another page, regardless of 
where the Web pages are actually located. For example, the initial Web page might be stored 
• on a Web server in New York and the second page (accessed via the hyperlink in the first 
page) might be stored on a Web server in California. 

The underlying principles of the Web were developed 1989 at the European Center for 
Nuclear Research (CERN) in Geneva. By 1994 there were approximately 500 Web servers on 
the Internet. Today there are more than a million, with new sites starting up at an 
extraordinary rate. In sum, the Web has become the center of Internet activity and is the 
primary reason for the explosive growth of the Internet over the past several years. 

In addition to providing a simple point-and-click interface to vast amounts of 
information on the Internet, the Web is quickly turning into a content delivery system. Well 
known Internet browsers such as Netscape Navigator™ and Microsoft Internet Explorer™ 
frequently provide plug-in software which allow additional features to be incorporated into the 
browser program. These include, for example, support for audio and video streaming, 
telephony, and videoconferencing. 



The unparalleled increase in Web usage combined with the incorporation of high 
bandwidth applications (i.e., audio and video) into browser programs has created serious 
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performance/bandwidth problems for most Internet Service Providers (hereinafter "ISPs"). 
Moreover, the network traffic resulting from non- Web-based Internet services such as Internet 
News (commonly known as "Usenet" News) has increased on the same scale as the increase 
in Web traffic, thereby further adding to the bandwidth problems experienced by most ISPs. 

These issues will be described in more detail with respect to Figure 1 which illustrates 
an ISP 100 with a link 160 to a larger network 150 (e.g., the Internet) through which a 
plurality of clients 130, 120 can access a plurality of Web servers 140-144 and/or News 
servers 146-148. Maintaining a link 160 to the Internet 150 with enough bandwidth to handle 
the continually increasing traffic requirements of its clients 120, 130 represents a significant 
cost for ISP. At the same time, ISP 1 10 must absorb this cost in order to provide an adequate 
user experience for its clients 120, 130. 

One system which is currently implemented to reduce network traffic across link 160 
is a proxy server 210 with a Web cache 220, illustrated in Figure 2. When client 120 initially 
clicks on a hyperlink and requests a Web page (shown as address "www.isp.com/page.html") 
stored on Web server 144, client 120 will use proxy server 210 as a "proxy agent." This 
means that proxy server 210 will make the request for the Web page on behalf of client 120 as 
shown. Once the page has been retrieved and forwarded to client 120, proxy server will store 
a copy of the Web page locally in Web cache 220. Thus, when client 120 or another client - 
e.g., client 130 - makes a subsequent request for the same Web page, proxy server 210 will 
immediately transfer the Web page from its Web cache 210 to client 130. As a result, the 
speed with which client 130 receives the requested page is substantially increased, and at the 
same time, no additional bandwidth is consumed across Internet link 160. 

While the foregoing proxy server configuration alleviates some of the network traffic 
across Internet link 160, several problems remain. One problem is that prior Web cache 
configurations do not have sufficient intelligence to deal with certain types of Web pages (or 
other Web-based information). For example, numerous Web pages and associated content 
can only be viewed by a client who pays a subscriber fee. As such, only those clients which 
provide proper authentication should be permitted to download the information. Today, proxy 
servers such as proxy server 210 will simply not cache a Web document which requires 
authentication. 
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In addition, Web caches do not address the increasing bandwidth problem associated 
with non-Web based Internet information. In particular, little has been done to alleviate the 
increasing bandwidth problems created by Usenet news streams. In fact, ISPs today must set 
aside a substantial amount of bandwidth to provide a continual Usenet news feed to its clients. 
Moreover, no mechanism is currently available for caching other data transmissions such as 
the streaming of digital audio and video. The term "streaming" implies a one-way 
transmission from a server to a client which provides for uninterrupted sound or video. When 
receiving a streaming transmission, the client will buffer a few seconds of audio or video 
information before it starts sending the information to a pair of speakers and/or a monitor, 
thus compensating for momentary delays in packet delivery across the network. 

Accordingly, what is needed is a content delivery system which will reduce the 
bandwidth requirements for ISP 1 10 while still providing clients 120, 130 with an adequate 
user experience. What is also needed is a system which will work seamlessly with different 
types of Web-based and non- Web-based information and which can be implemented on 
currently available hardware and software platforms. What is also needed is an intelligent 
content delivery system which is capable of caching all types of Web-based information, 
including information which requires the authentication of a client before it can be accessed. 
What is also needed is a content delivery system which is easily adaptable so that it can be 
easily reconfigured to handle the caching of new Internet information and protocols. Finally, 
what is needed is a data replication system which runs on a distributed database engine, 
thereby incorporating well known distributed database procedures for maintaining cache 
coherency. 

SUMMARY OF THE INVENTION 

Disclosed is a network content delivery system configured to: select a first content 
routing technique for processing a first set of network content; and select a second content 
routing technique for processing a second set of network content, wherein the first and second 
content routing techniques are selected based on one or more content routing variables. 

Also disclosed is a content delivery system comprising: a network node for storing 
network content; a first transmission medium communicatively coupled to the network node 
for transmitting a first set of network content to the network node; and a second transmission 
medium communicatively coupled to the network node for transmitting a second set of 
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network content to the network node, wherein the first and second sets of network content are 
selected based on one or more routing variables. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A better understanding of the present invention can be obtained from the following 
detailed description in conjunction with the following drawings, in which: 

FIG. 1 illustrates generally a network over which an ISP and a plurality of servers 
communicate. 

FIG. 2 illustrates an ISP implementing a proxy server Web cache. 

FIG. 3 illustrates one embodiment of the underlying architecture of an Internet content 
delivery system node. 

FIG. 4 illustrates a plurality of Internet content delivery system nodes communicating 
across a network. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

One embodiment of the present system is a computer comprising a processor and a 
memory with which software implementing the functionality of the internet content delivery 
system described herein is executed. Such a computer system stores and communicates 
(internally or with other computer systems over a network) code and data using machine 
readable media, such as magnetic disks, random access memory, read only memory, carrier 
waves, signals, etc. In addition, while one embodiment is described in which the parts of the 
present invention are implemented in software, alternative embodiments can implement one 
or more of these parts using any combination of software, firmware and/or hardware. 

The underlying architecture of one embodiment of the present internet content delivery 
system (hereinafter "ICDS") is illustrated in Figure 3. A single ICDS node 300 is shown 
including a cache 330, an ICDS application programming interface (hereinafter "API") 360 
which includes a distributed database engine 361, and a plurality of software modules 310-326 
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which interface with the ICDS API 360. ICDS node 300 may communicate over a network 
340 (e.g., the Internet) over communication link 370 and may also interface with a plurality of 
clients 350-35 1 and/or other ICDS nodes (e.g., through link 380). 

As is known in the art, an API such as ICDS API 360 is comprised of a plurality of 
subroutines which can be invoked by application software (i.e., software written to operate in 
conjunction with the particular API). Thus, in Figure 3 each of the plurality of software 
modules 310-326 may be uniquely tailored to meet the specific needs of a particular ISP. The 
modules interface with API 360 by making calls to the APFs set of predefined subroutines. 
Another significant feature of ICDS API 360 is that it is platform-independent. Accordingly, 
it can be implemented on numerous hardware platforms including those that are Intel-based, 
Macintosh-based and Sun Microsystems-based. 

In one embodiment, a portion of API 360* s subroutines and a set of prefabricated 
modules can be marketed together as a Software Development Kit (hereinafter "SDK"). This 
will allow ISPs, corporations and/or end-users to customize the type of internet content 
delivery/caching which they require. In addition, because modules 3 10-326 may be 
dynamically linked, they may be loaded and unloaded without having to reboot the hardware 
platform on which cache 330 is executed. 

I. Distributed Content Processine 

As illustrated, ICDS node 300 includes a plurality of network protocol modules 310- 
319 which interface with API 360. These modules provide caching support on ICDS node 
300 for numerous different Internet protocols including, but not limited to, Web protocols 
such as the Hypertext Transfer Protocol (hereinafter "HTTP") 310, Usenet news protocols 
such as the Network News Transport Protocol (hereinafter "NNRP") 312, directory access 
protocols such as the Lightweight Directory Access Protocol (hereinafter "LDAP") 3 14, data 
streaming protocols such as the Real Time Streaming Protocol (hereinafter "RTSP") 316, and 
protocols used to perform Wide Area Load Balancing (hereinafter "WALB") 318. Because 
the underlying architecture of the present ICDS system includes an open API, new protocol 
modules (e.g., module 319) can be seamlessly added to the system as needed. 

One embodiment of the ICDS system includes a plurality of standardized service 
definitions through which individual service modules 320-326 may be configured to interface 
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with the ICDS API 360. These service modules provide the underlying functionality of ICDS 
node 300 and may include a data services module 320, an access services module 322, a 
transaction services module 323, a commercial services module 324, a directory services 
module 325, and a resource services module 326, The functionality of each of these modules 
will be described in more detail below. 

In one embodiment of the ICDS system, the ICDS API includes a distributed relational 
database engine 361. As a result, a plurality of ICDS nodes 410-440 can be distributed across 
ISP 400's internal network and still maintain a coherent, up-to-date storage of Internet 
content. For example, if a particular data object is updated at two nodes simultaneously, the 
underlying distributed database system may be configured to resolve any conflicts between the 
two modifications using a predefined set of distributed database algorithms. Accordingly, the 
present system provides built in caching support for dynamically changing Internet content 
(e.g., Web pages which are modified on a regular basis). Such a result was not attainable with 
the same level of efficiency in prior art caching systems such as proxy server 210 of Figure 2 
(which are executed on, e.g., standard flat file systems such as UNIX or NFS file servers). 

Data Services 

Data services modules such as module 320 running on each ICDS node 410-440 
provide support for data replication and distribution across ISP 400* s internal network 480. 
This includes caching support for any data protocol included in the set of protocol modules 
310-3 19 shown in Figure 3 as well as for any future protocol which may be added as a 
module to the ICDS API 360. Because the ICDS API 360 provides a set of standardized 
service definitions for data services module 320, an ISP using a plurality of ICDS nodes 300 
as illustrated in Figure 4 can replicate data across its network without an extensive knowledge 
of distributed database technology. In other words, the ISP can configure its plurality of nodes 
by invoking the standardized service definitions associated with data services module 320 and 
leave the distributed database functionality to the distributed database engine 36 L 

Generally, three different types of data replication may be implemented by the present 
system: dynamic replication, database replication (or "actual" replication), and index 
replication. Using dynamic replication, if client 472 requests content from internal ICDS 
server 460 or from a server across network 490, the content will be delivered to client 472 and 
replicated in ICDS node 430. If client 473 (or any other client) subsequently requests the 
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same content, it will be transmitted directly from ICDS node 430 rather than from its original 
source (i.e., a second request to server 460 or a server across network 490 will not be 
required). Accordingly, bandwidth across ISP 400' s internal network and across Internet link 
405 is conserved. 

The dynamic replication mechanism just described works well for replicating static 
content but not for replicating dynamically changing content. For example, if the replicated 
content is a magazine article then caching a copy locally works well because it is static 
information - i.e., there is no chance that the local copy will become stale (out of date). 
However, if the replicated content is a Web page which contains continually changing 
information such as a page containing stock market quotes, then dynamic replication may not 
be appropriate. No built in mechanism is available for proxy cache server 210 to store an up- 
to-date copy of the information locally. 

The present ICDS system, however, may use database replication to maintain up-to- 
date content at each ICDS node 410-440. Because the present system includes a distributed 
database engine 361, when a particular piece of content is changed at one node (e.g., ICDS 
server 460) a store procedure may be defined to update all copies of the information across the 
network. This may be in the form of a relational database query. Thus, the present system 
may be configured to use dynamic replication for static content but to use database replication 
for time-sensitive, dynamically changing content. 

The third type of database replication is known as index replication. Using index 
replication a master index of content is replicated at one or more ICDS nodes 410-440 across 
the network 480. Once again, this implementation is simplified by the fact that the underlying 
ICDS node engine is a distributed database engine. Certain types of information distributions 
are particularly suitable for using index replication. For example, news overview information 
(i.e., the list of news articles in a particular newsgroup) is particularly suited to index 
replication. Instead of replicating each individual article, only the news overview information 
needs to be replicated at various nodes 410-440 across the network 480. When a client 473 
wants to view a particular article, only then will the article be retrieved and cached locally 
(e.g., on ICDS node 430). 
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ICDS node 430 is capable of caching and delivering various types of Internet data 
using any of the foregoing replication techniques. While prior art proxy servers such as proxy 
server 210 may only be used for caching Web pages, ICDS node 430 is capable of caching 
various other types of internet content (e.g., news content) as a result of the protocol modules 
3 10-3 19 interfacing with ICDS API 360. Moreover, as stated above, ICDS node 430 (in 
conjunction with nodes 410, 420 and 440) may be configured to cache dynamic as well as 
static Web-based content using various distributed database algorithms. 

One specific example of a data service provided by one embodiment of the present 
system is Wide Area Load Balancing (hereinafter "WALB") using layer 7 switching as 
described in the co-pending U.S. Patent Application entitled "Wide Area Load Balancing" 

(Serial No. ), which is assigned to the assignee of the present application and which is 

incorporated herein by reference. The present system may also perform dynamic protocol 
selection, dynamic query resolution, and/or heuristic adaptation for replicating content across 
a network as set forth in the co-pending U.S. Patent Application entitled Dynamic Protocol 

Selection and "Query Resolution for Cache Servers" (Serial No. ), which is 

assigned to the assignee of the present application and which is incorporated herein by 
reference. Finally, the present system also may include network news (e.g., Usenet news) 
services set forth in the co-pending U.S. Patent Applications entitled "Hybrid News Server" 

(Serial No. ), and "Self-Moderated Virtual Communities" (Serial No. J, each 

assigned to the assignee of the present application and each incorporated herein by reference. 

Access Services 

As stated above, prior art proxy server cache systems such as proxy server 210 are 
only capable of caching static, publicly available Web pages. A substantial amount of Web- 
based and non-Web-based content, however, requires some level of authentication before a 
user will be permitted to download it. Thus, client 472 (in Figure 4) may pay a service fee to 
obtain access to content on a particular web site (e.g., from server 460 or from another server 
over network 490). As a result, when he attempts to access content on the site he will initially 
be prompted to enter a user name and password. Once the user transmits this information to 
the Web server, he will then be permitted to download Web server content as per his service 
agreement. 
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A problem that arises, however, is that prior art cache systems such as proxy server 
210 are not permitted to cache the requested content. This is because proxy server 210 has no 
way of authenticating subsequent users who may attempt to download the content. Thus, 
documents which require authentication are simply uncacheable using current network cache 
systems. 

The present ICDS system, however, includes user authentication support embedded in 
access services module 322. Thus, when client 473, for example, attempts to access a Web 
page or other information which requires authentication, ICDS node will determine whether 
the requested content is stored locally. If it is, then ICDS node 430 may communicate with 
the authentication server (e.g., server 460 or any server that is capable of authenticating client 
473* s request) to determine whether client 473 should be granted access to the content. This 
may be accomplished using standardized authentication service definitions embedded in 
access services module 322. Using these definitions, ICDS node 430 will not only know what 
authentication server to use, it will also know what authentication protocol to use when it 
communicates to the authentication server. As a result of providing local access services 
module 322 for authentication, network information which requires authentication can now be 
cached locally in ICDS node 430, thereby conserving additional bandwidth across network 
link 405 and/or ISP network 480. 

One particular embodiment of the present system replicates Remote Authentication 
Dial In User Service (hereinafter "RADIUS") information across network 480. RADIUS is an 
application-level protocol used by numerous ISP's to provide user authentication and profile 
services. This is achieved by setting up a central RADIUS server with a database of users, 
which provides both authentication services (i.e., verification of user name and password) and 
profile services detailing the type of service provided to the user (for example, SLIP, PPP, 
telnet, rlogin). 

Users connect to one or more Network Access Servers (hereinafter "NASs") which 
operate as a RADIUS clients and communicate with the central RADIUS server. The NAS 
client passes the necessary user information to the central RADIUS server, and then acts on 
the response which is returned. RADIUS servers receive user connection requests, 
authenticate users, and then return all configuration information necessary for the client to 
deliver service to the user. 
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One problem associated with the RADIUS protocol is that it does not provide any built 
in facilities for replication of RADIUS information. Accordingly, on large ISP's such as 
America Online ("AOL"), which may have tens of millions of users, RADIUS servers are 
hard hit, potentially handling thousands of logon requests a minute. This may create severe 
performance/bandwidth problems during high traffic periods. In response, some ISP's have 
taken a brute-force approach to distributing RADIUS information by simply copying the 
information to additional servers across the network without any built in mechanism to keep 
the RADIUS data coherent and up-to-date. 

One embodiment of the present ICDS system provides an efficient, dynamic 
mechanism for distributing RADIUS information. Specifically, a RADIUS module is 
configured to interface with ICDS API 360 in this embodiment (similar to the way in which 
protocol modules 310-319 interface with the ICDS API 360). RADIUS information can them 
be seamlessly distributed across the system using distributed database engine 361. For 
example, the RADIUS module in conjunction with access services module 322 on ICDS node 
430 may maintain radius information for local users. [Exactly how will this work? I assume 
that access services module will be used but there will be a separate RADIUS protocol 
module to support the protocol??] Thus, when client 472 first logs in to the system, ICDS 
node 430 may communicate with a second ICDS node (e.g., central ICDS server 460) which 
contains the necessary RADIUS authentication and user profile information. Client 472 will 
input a user name and password and will then be permitted access to the network as per his 
service agreement with ISP 400. 

Unlike previous RADIUS systems, however, ICDS node 430 in the present 
embodiment may locally cache client 472's RADIUS information so that the next time client 
472 attempts to login to the network, the information will be readily available (i.e., no access 
to a second ICDS node will be necessary). ICDS node 430 may be configured to save client 
472' s RADIUS information locally for a predetermined period of time. For example, the 
information may be deleted if client 472 has not logged in to local ICDS node 430 for over a 
month. 

Thus, if client 472 represents a user who frequently travels across the country and logs 
in to ISP 400' s network 480 from various different ICDS nodes, the present system provides a 
quick, effective mechanism for dynamically replicating client 472' s user information into 



WO 00/73922 




PCT/US00/11078 



11 



those geographical locations from which he most commonly accesses ISP 400. This reduces 
the load which would otherwise be borne by a central RADIUS server and also improves 
client 472's user experience significantly (i.e., by providing him with a quick login). 

Database replication can also be used to update RADIUS information distributed 
across multiple ICDS nodes 410-440. This may be done using known store procedures 
defined in relational database 361. For example, if client 472 cancels his service agreement 
with ISP 400, he should not be able to continually log in to local ICDS node 430 using the 
RADIUS information which has been cached locally. Thus, under the present ICDS system, 
ISP 400 may simply issue a relational database query such as [let's add another update query 
here using database terminology as an example] to immediately update ICDS node 430's 
radius information. 

One of ordinary skill in the art will readily recognize from the preceding discussion 
that alternative embodiments of the structures and methods illustrated herein may be 
employed without departing from the principles of the invention. Throughout the foregoing 
' description, specific embodiments of the ICDS system were described using the RADIUS 
protocol in order to provide a thorough understanding of the operation of the ICDS system. It 
will be appreciated by one having ordinary skill in the art, however, that the present invention 
may be practiced without such specific details. For example, the ICDS system may also 
distribute authentication and user profile information in the form of the Lightweight Directory 
Access Protocol ("LDAP"). In other instances, well known software and hardware 
configurations/techniques have not been described in detail in order to avoid obscuring the 
subject matter of the present invention. 

Access services module 322 may also provide local encryption/decryption and 
watermarking of internet content. Audio or video content delivery systems, for example, 
commonly use encryption of content to protect the rights of the underlying copyright holder. 
When a user requests a particular piece of content some delivery systems encrypt the content 
using a unique client encryption key. Only a client who possesses the encryption key 
(presumably the client who paid for the content) will be permitted to play the content back. 
Other systems provide for the "watermarking" of content (rather than encrypting) so that the 
rightful owner of the content may be identified. This simply entails embedding a unique "tag' 
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which identifies the source of the content and/or the owner of the content (i.e., the one who 
paid for it). 

Prior art caching systems such as proxy server 210 are not capable of dealing with 
encrypted or watermarked content because the encryption/watermarking functionality was not 
provided locally (i.e., proxy server 210 was not "smart" enough). In one embodiment of the 
present ICDS system, however, access services module 322 of ICDS nodes 410-440 includes 
a local encryption module and/or a local watermarking module. For example, if client 473 
requests specific content such as a copyrighted music content stored on a music server (e.g., 
ICDS server 460), the initial request for the content will be made from ICDS node 430 on 
behalf of client 473. ICDS node 430 will retrieve the requested content and cache it locally. 
If the requested content requires encryption, ICDS node 430 will use its local encryption 
module to encrypt the requested content using a unique user encryption key for client 473. 

If a second client - e.g., client 472 - requests the same content, the copy stored locally 
on ICDS module 430 can be used. ICDS module 430 will simply encrypt the content using a 
different encryption key for user 472. Thus, frequently requested multimedia content (which, 
as is known in the art, can occupy a substantial amount of storage space) may be cached 
locally at ICDS node 430 notwithstanding the fact that the content requires both user 
authentication and encryption. 

The same functionality may be provided for watermarking of content. ICDS node will 
use a watermarking module (which may comprise a component of access services module 
322) to individually watermark multimedia information requested by individual clients, 
thereby protecting the rights of the copyright holder of the underlying multimedia content. 
This information can then be regularly communicated back to a central database repository. 

As is known in the art, multimedia files can be extremely large and, accordingly, take 
substantially more time to communicate across a network than do, for example, generic Web 
pages. As such, the ability to locally cache multimedia files significantly reduces traffic 
across network 480, and also significantly improves the user experience for local users when 
downloading multimedia information. 
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Transaction Services 
In addition to replicating data services and access services information across a 
network, the present ICDS system also provides for the replication of transaction services. 
Transaction services includes maintaining information on client payments for use of ISP 400' s 
services as well as information relating to the client's online access profile (i.e., recording of 
the times when the user is online). 

When a client logs in to an ISP today, the client's online information is maintained on 
a single central server. The central server maintains records of when and for how long the 
client logged in to the network and may also include information about what the client did 
while he was online. As was the case with maintaining a central RADIUS server, maintaining 
a central transaction server for all users of a large ISP is inefficient and cumbersome. The 
present system solves the performance and bandwidth problems associated with such a 
configuration by storing transaction information locally via transaction module 323 and 
algorithms build around distributed database engine 361. 

Thus, if client 472 only logs on to ISP 400' s network 480 via ICDS node 430, all of 
his transaction and billing information will be stored locally. The information may then be 
communicated across network 480 to a central billing server at predetermined periods of time 
(e.g., once a month). [We didn't go into great detail on transaction services and the rest; 
please add information as you feel appropriate] 

Commercial Services 

Commercial services module 324 provides a significantly improved local caching 
capability for add rotation and accounting. An add rotation system operating in conjunction 
with a typical proxy cache server will now be described with respect to Figure 2. When client 
120 downloads a web page from Web server 142 the Web page may contain an ad tag or an 
add tag may automatically be inserted. The add tag will identify add server 170 and will 
indicate that an add should be inserted into the requested Web page from add server 170. Add 
server will then identify a specific add to insert into the downloaded Web page from add 
content server. The Web page plus the inserted add will then be forwarded to proxy server 
2 10 and on to client 120. 
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Add server 170 will keep an accounting of how many different users have downloaded 
Web pages with adds inserted as described above. However, one problem with accounting on 
this system is that proxy server 210 requests Web pages on behalf of Ms clients. Accordingly, 
once the requested Web pages has been cached locally in Web cache 220, add server will only 
receive requests from proxy server 210 for any subsequent requests for the Web page. This 
will result in an inaccurate accounting of how many unique clients actually requested the Web 
page (and how many adds were viewed by unique users). 

Because one embodiment of the present system provides built in caching support for 
ad rotation services, an accurate accounting of the number of hits that a particular ad receives 
may be maintained. More specifically, one embodiment of the present ICDS system solves 
this problem by providing a commercial services module that monitors and records how often 
individual clients request Web pages containing particular adds from add content server 171. 
This information than then be communicated to a central server (e.g., ICDS server 460) at 
predetermined intervals for generating add rotation usage reports. 

Directory Services 

Directory services provide the ability to cache locally a directory of information across 
network 480 or 490. That is, the question here is not whether the particular information is 
available but where exactly over networks 480 or 490 it is located. It should be noted that 
there may be some overlap between the directory services concept and the index replication 
concept described above with respect to data services. [I'm still not 100% sure what this is - 
please elaborate with an example] 

II. Content Routing 

The term "content routing" refers to the ability to select among various 
techniques/protocols for maintaining a coherent set of content across a network. The selection 
of a particular technique may be based on several routing variables including, but not limited 
to, the type of content involved (i.e., FTP, HTTP . . . etc), the size of the content involved (i.e., 
small files such as HTTP vs. large files such as audio/video streaming), the location of the 
content on network 480 and/or network 490, the importance of a particular piece of content 
(i.e., how important it is that the content be kept up-to-date across the entire network), the 
particular user requesting the content and the terms of his subscription agreement (i.e., some 
users may be willing to pay more to be insured that they receive only the most up-to-date 
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content without having to wait), the frequency with which the content is accessed (e.g., 5%- 
10% of content on the Internet represents 90% of all the requested content), and the 
underlying costs and bandwidth constraints associated with maintaining up-to-date, coherent 
content across a particular network (e.g., network 480). 

Three content routing techniques which may be selected (based on one or more of the 
foregoing variables) to maintain coherent content across the plurality of nodes illustrated in 
Figure 4 are content revalidation, content notification, and content synchronization. 

Content Revalidation 

When content validation is selected, the original content source will be checked only 
when the content is requested locally. For example, client 473 may request an installation 
program for a new Web browser (e.g., the latest version of Microsoft's™ Internet 
Explorer™). The file may then be transmitted form ICDS server 460 to client 473 and a copy 
of the file cached locally on ICDS node 430. Consequently, if client 472 requests the same 
program, for example, two weeks later, ICDS node 430 may be configured to check ICDS 
server 460 to ensure that it contains the most recent copy of the file before passing it on to 
client 472 (i.e., ICDS node 430 "revalidates" the copy it has locally). 

ICDS node 430 may also be configured to revalidate a piece of content only if has 
been stored locally for a predetermined amount of time (e.g., 1 week). The particular length 
of time selected may be based on one or more of the variables discussed above. Moreover, in 
one embodiment, the age/revision of a particular piece of content is determined based on tags 
(e.g., HTML metatags) inserted in the particular content/file. 

Revalidation may work more efficiently with certain types of content than with others. 
For example, revalidation may be an appropriate mechanism for maintaining up-to-date copies 
of larger files which do not change very frequently (i.e., such as the program installation files 
described above). However, revalidation may not work as efficiently for caching smaller 
and/or continually changing files (e.g., small HTML files) because the step of revalidating 
may be just as time* consuming as making a direct request to ICDS server 460 for the file 
itself. If the file in question is relatively small and/or is changing on a minute-by-minute basis 
(e.g., an HTML file containing stock quotes) then one or more other content routing 
techniques may be more appropriate. 
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Of course, other routing variables may influence the decision on which technique to 
use, including the issue of how strong the data transmission connection is between ICDS node 
430 and ICDS server 460 (i.e., how reliable it is, how much bandwidth is available . . . etc) 
and the necessity that the underlying information cached locally (at ICDS node 430) be 
accurate. The important thing to remember is that ICDS node 430 - because of its underlying 
open API architecture - may be configured based on the unique preferences of a particular 
client. 

Content Notification 
Content notification is a mechanism wherein the central repository for a particular 
piece of content maintains a list of nodes, or "subscribers," which cache a copy of the content 
locally. For example, in Figure 4, a plurality of agents may run on ICDS server 460 which 
maintain a list of content subscribers (e.g., ICDS node 430, ICDS node 420 . . . etc) for 
specific types of content (e.g., HTML, data streaming files, FTP files . . . etc). In one 
embodiment of the system, a different agent may be executed for each protocol supported by 
ICDS server 460 and/or ICDS nodes 410-440. 

When a particular piece of content is modified on ICDS server 460, a notification of 
the modification may be sent to all subscriber nodes (i.e., nodes which subscribe to that 
particular content). Upon receiving the notification, the subscriber node - e.g., ICDS node 
430 - may then invalidate the copy of the content which it is storing locally. Accordingly, the 
next time the content is requested by a client (e.g., client 472), ICDS node 430 will retrieve 
the up-to-date copy of the content from ICDS server 460. The new copy will then be 
maintained locally on ICDS node 430 until ICDS node 430 receives a second notification 
from an agent running on ICDS server 460 indicating that a new copy exists. 

Alternatively, each time content is modified on ICDS server 460 the modified content 
may be sent to all subscriber nodes along with the notification. In this manner a local, up-to- 
date copy of the content is always ensured. In one embodiment of the system, notification 
and/or transmittal of the updated content by the various system agents is done after a 
predetermined period of time has elapsed (e.g., update twice a day). The time period may be 
selected based on the importance of having an up-to-date copy across all nodes on the network 
480, 490. 
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As was the case with content revalidation, the different varieties of content notification 
may work more efficiently in some situations than in others. Accordingly, content notification 
may be selected as a protocol (or not selected) based on one or more of the routing variables 
recited at the beginning of this section (i.e. t the "content routing" section). For example, 
content notification may be an appropriate technique for content which is frequently requested 
at the various nodes across networks 480 and 490 (e.g., for the 5-10% of the content which is 
requested 90% of the time), but may be a less practical technique for larger amount of content 
which is requested infrequently. As another example, large files which change frequently may 
not be well suited for content notification (i.e., particularly the type of content notification 
where the actual file is sent to all subscribers along with the notification) due to bandwidth 
constraints across networks 480 and/or 490 (i.e., the continuous transmission of large, 
frequently changing files may create too much additional network traffic). 

Content Synchronization 

Content synchronization is a technique for maintaining an exact copy of a particular 
type of content on all nodes on which it is stored. Using content synchronization, as soon as a 
particular piece of content is modified at, for example, ICDS node 430, it will immediately be 
updated at all other nodes across networks 480 and/or 490. If the same piece of data was 
concurrently modified at one of its other storage locations (e.g., ICDS node 410) then the 
changes may be backed off in order to maintain data coherency. Alternatively, an attempt 
may be made to reconcile the two separate modifications if it is possible to do so (using, e.g., 
various data coherency techniques). 

Once again, as with content notification and content revalidation, content 
synchronization is more suitable for some situations than it is for others. For example, 
content synchronization is particularly useful for information which can be modified from 
several different network nodes (by contrast, the typical content notification paradigm 
assumes that the content is modified at one central node). Moreover, content synchronization 
may be useful for maintaining content across a network which it is particularly important to 
keep current. For example, if network 480 is an automatic teller machine (hereinafter 
"ATM") network, then when a user withdraws cash from a first node (e.g., ICDS node 440), 
his account will be instantly updated on all nodes (e.g., ICDS node 410, 420, 460, and 430) to 
reflect the withdrawal. Accordingly, the user would not be able to go to a different node in a 
different part of the country and withdraw more than what he actually has in his account. 
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As another example, a user's account status on a network (i.e., whether he is a current 
subscriber and/or what his network privileges are) may be maintained using content 
synchronization. If, for example, a user of network 480 were arrested for breaking the law 
over network 480 (e.g., distributing child pornography), it would be important to disable his 
user account on all network nodes on which this information might be cached. Accordingly, 
using content synchronization, once his account was disabled at one node on network 480 this 
change would automatically be reflected across all nodes on the network. 

As previously stated, the choice of which content routing technique to use for a 
particular type of content may be based on any of the variables set forth above. In one 
embodiment, the frequency with which content is accessed across the networks 480 and/or 
490 may be an important factor in deciding which protocol to use. For example, the top 1% 
accessed content may be selected for content synchronization, the top 2%-10% accessed 
content may be selected for content notification, and the remaining content across networks 
480, 490 may be selected for content revalidation. 

III. Content Delivery Medium Selection 

In addition to the content routing flexibility provided by the content delivery system as 
set forth above, one embodiment of the system allows content delivery nodes such as ICDS 
node 430 to select from a plurality of different transmission media. For example, ICDS node 
430 may receive content from ICDS server 460 via a plurality of communication media, 
including, but not limited to, satellite transmission, wireless RF transmission, and terrestrial 
transmission (e.g., fiber). 

Moreover, as with the selection of a particular content routing technique, the selection 
of a particular transmission medium may be based on any of the variables set forth above (see, 
e.g., routing variables listed under counter routing heading; page 24, line 18 through page 25, 
line 9). Moreover, the choice of a particular transmission medium may be dynamically 
adjustable based on performance of that medium. For example, ICDS node 430 may be 
configured to receive all of its content over terrestrial network 480 as long as network 480 is 
transmitting content at or above a threshold bandwidth. When transmissions over network 
480 dip below the threshold bandwidth, ICDS node 480 may then begin receiving certain 
content via satellite broadcast or wireless communication. 
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In addition, a transmission medium may be selected for transmitting specific content 
based on how frequently that content is accessed. For example, the top 10% frequently 
accessed content may be continually pushed out to ICDS node 430 via satellite broadcast 
while the remaining content may be retrieved by (i.e., "pulled" to) ICDS node 430 over 
network 480 upon request by clients (e.g., client 473). Accordingly, those employing ICDS 
nodes such as node 430 can run a cost-benefit analysis to determine the most cost effective 
way to implement their system by taking in to consideration, for example, the needs of their 
users, the importance of the content involved and the expense of maintaining multiple 
transmission connections into ICDS node 430 (e.g., the cost associated with maintaining an 
ongoing satellite connection). 

In one embodiment of the system, tags (e.g., HTML metatags) may be inserted into 
particular types of content to identify a specific transmission path/medium for delivering that 
content to ICDS node 480. The tags in this embodiment may identify to various nodes (and/or 
routers) across networks 480 and/or 490 how the particular content should be routed across 
the networks (e.g., from node 410 to node 420 via terrestrial network 480; from node 420 to 
node 430 via tireless transmission). 

One of ordinary skill in the art will readily recognize from the preceding discussion 
that alternative embodiments of the structures and methods illustrated herein may be 
employed without departing from the principles of the invention. Throughout this detailed 
description, numerous specific details are set forth such as specific network protocols (i.e., 
RADIUS) and networks (i.e., the Internet) in order to provide a thorough understanding of the 
present invention. It will be appreciated by one having ordinary skill in the art, however, that 
the present invention may be practiced without such specific details. In other instances, well 
known software and hardware configurations/techniques have not been described in detail in 
order to avoid obscuring the subject matter of the present invention. The invention should, 
therefore, be measured in terms of the claims which follow. 
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CLAIMS 

What is claimed is: 

1 . A network content delivery system configured to: 

select a first content routing technique for processing a first set of network content; 

and 

select a second content routing technique for processing a second set of network 
content, wherein said first and second content routing techniques are selected based on one or 
more content routing variables. 

2. The network content delivery system as claimed in Claim 1 wherein one of said 
selected content routing techniques is a content revalidation technique. 

3. The network content delivery system as claimed in Claim 1 wherein one of said 
selected content routing techniques is a content notification technique. 

4. The network content delivery system as claimed in Claim 1 wherein one of said 
selected content routing techniques is a content synchronization technique. 

5. The network content delivery system as claimed in Claim 1 wherein one of said 
content routing variables is the frequency with which said network content is accessed by 
users. 

6. The network content delivery system as claimed in Claim 1 wherein one of said 
content routing variables is the size of said network content. 

7. The network content delivery system as claimed in Claim 1 wherein one of said 
content routing variables is the frequency with which said network content is modified. 

8. The network content delivery system as claimed in Claim 1 wherein one of said 
content routing variables is the type of network content (e.g., HTML, Usenet News). 

9. The network content delivery system as claimed in Claim 1 wherein one of said 
content routing variables is identity of the user requesting said network content. 

10. The network content delivery system as claimed in Claim 2 wherein said content 
revalidation technique is selected based on the size of said network content. 

11. The network content delivery system as claimed in Claim 2 wherein said content 
revalidation technique is selected based on the frequency with which said network content is 
accessed. 

12. The network content delivery system as claimed in Claim 3 wherein said content 
notification technique is selected based on the size of said network content. 
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13. The network content delivery system as claimed in Claim 3 wherein said content 
notification technique is selected based on the frequency with which said network content is 
accessed. 

14. The network content delivery system as claimed in Claim 4 wherein said content 
synchronization technique is selected based on the size of said network content. 

15. The network content delivery system as claimed in Claim 4 wherein said content 
synchronization technique is selected based on the frequency with which said network content 
is accessed. 

16. The network content delivery system as claimed in Claim 1 including the 
additional step of selecting a first transmission medium for a first group of network content 
based on one or more of said content routing variables. 

17. The network content delivery system as claimed in Claim 16 including the 
additional step of selecting a second transmission medium for a second group of network 
content based on one or more of said content routing variables. 

18. The network content delivery system as claimed in Claim 1 including an 
application programming interface for interfacing with a plurality of network protocol and 
service modules. 

19. A content delivery system comprising: 
a network node for storing network content; 

a first transmission medium communicatively coupled to said network node for 
transmitting a first set of network content to said network node; and 

a second transmission medium communicatively coupled to said network node for 
transmitting a second set of network content to said network node, 

wherein said first and second sets of network content are selected based on one or 
more routing variables. 

20. The content delivery system as claimed in Claim 19 wherein said first 
transmission medium is a satellite transmission. 

21. The content delivery system as claimed in Claim 19 wherein said first 
transmission medium is a wireless radio frequency transmission. 

22. The content delivery system as claimed in Claim 19 wherein said first 
transmission medium is terrestrial-based transmission. 

23. The content delivery system as claimed in Claim 19 wherein said network node 
monitors transmission bandwidth of said first transmission medium and reallocates content 
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from said first set to said second set if said first transmission medium drops below a 
predetermined threshold value. 

24. The content delivery system as claimed in Claim 23 wherein said first 
transmission medium is terrestrial and said second transmission medium is non-terrestrial. 

25. The content delivery system as claimed in Claim 19 wherein content is included 
in said first set based on the frequency with which said content is accessed. 

26. The network content delivery system as claimed in Claim 19 including an 
application programming interface for interfacing with a plurality of network protocol and 
service modules. 

27. An article of manufacture including a sequence of instructions stored on a 
computer-readable media which, when executed by a network node, cause the network node 
to perform the acts of: 

establishing a plurality of groups of network content to be cached on said network 
node based on one or more content routing variables; 

selecting a first content routing technique for maintaining data coherency in a first 
group of said plurality; and 

selecting a* second content routing technique for maintaining data coherency in a 
second group of said plurality. 

28. The article of manufacture as claimed in claim 27 wherein said first content 
routing technique is content revalidation. 

29. The article of manufacture as claimed in Claim 28 wherein said second content 
routing technique is content notification. 

30. The article of manufacture as claimed in Claim 28 wherein said second content 
routing technique is content synchronization. 

31. The article of manufacture as claimed in Claim 28 wherein said content routing 
variable used to select said content for said first group is the frequency with which said 
content is accessed. 

32. The article of manufacture as claimed in Claim 29 wherein said content routing 
variable used to select said content for said first group is the frequency with which said 
content is accessed. 

33. The article of manufacture as claimed in Claim 30 wherein said content routing 
variable used to select said content for said first group is the frequency with which said 
content is accessed. 
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34. A network node comprising: 

an application programming interface ("API"), said API including a distributed 
relational database engine; 

a plurality of protocol modules for interfacing with said API, said protocol modules 
configured to allow said system to communicate over a network using a plurality of network 
protocols; 

a cache memory for caching data communicated to said cache memory using said 
plurality of protocol modules; and 

a data services module for maintaining coherency between said data stored in said 
cache memory and data stored at other nodes across said network. 
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